📖 [타입으로 견고하게 다형성으로 유연하게] 책 제목 이해하기

최근 이선협님이 작성하신 Type-Driven-Development 포스팅을 읽었습니다.

흥미로웠고 호기심이 생겼습니다.

그래서 댓글을 남겼습니다. 작성하신 내용을 학습하기 위해선 무엇을 학습해야 하는지에 대해서요.

타입으로 견고하게 다형성으로 유연하게라는 책을 추천해주셨고, 바로 구매해서 다음날부터 읽었습니다.

이번 포스팅에서는 책을 읽고 책 제목의 의미를 정리해보았습니다.

책에서는 특정 언어 기반 설명이 아닌, 다양한 언어의 예시를 통해 설명을 제공하지만

저는 익숙한 타입스크립트로 정리해보았습니다.

책 내용 이외에도 잉여 속성 검사와 타입스크립트 다큐멘터리에서 본 흥미로운 내용을 일부 담았습니다.

여러분도 흥미로웠으면 좋겠습니다. :)

목차

• 타입으로 견고하게
  • 타입이란 무엇일까?
  • 타입으로 견고하게란 무엇일까?
  • 타입스크립트의 탄생 배경
• 다형성으로 유연하게
  • 다형성이란 무엇일까?
  • 서브타입이란 무엇일까?
  • 서브타입 관계를 타입 검사기에 알리는 extends 키워드
  • 서브타입에 의한 다형성이란 무엇일까?
  • 구조적 타이핑이란 무엇일까?
  • 잉여 속성 검사란 무엇일까?
  • 타입스크립트 탄생 배경에서 살펴본 구조적 타이핑
• 마무리

타입으로 견고하게

타입은 정적 타입 언어를 사용해본 분들이라면 누구나 경험상 어떤것인지 감이 오실겁니다.

그렇다 하더라도 타입으로 견고하게 라는 의미는 살펴보기 위해서 타입에 대한 정의부터 시작하는게 좋을것 같습니다.

타입이란 무엇일까?

타입이란 무엇일까요?

저자가 이야기한바는 다음과 같습니다.

값이 가진 능력에 따라 분류 한 것. 

능력이란 말이 추상적으로 느껴질 수 있을것 같습니다.

구체적인 예시를 통해 이해해 보겠습니다.

문자는 어떤 능력을 가질까요?

'abc'는 자바스크립트에서 리터럴 표기법을 통해 생성한 문자입니다.

문자는 프로토타입 상속(참조)을 통해 'at', 'substring', 'match' 등의 능력을 갖습니다.

배열은 어떤 능력을 가질까요?

[1,2,3]는 자바스크립트에서 리터럴 표기법을 통해 생성한 배열입니다.

배열은 프로토타입 상속(참조)을 통해 'map', 'filter', 'reduce' 등의 능력을 갖습니다.

하지만 값이 가진 능력에 벗어난 일을 시키면 타입 오류가 발생합니다.

'abc'.filter() // type error
[1,2,3].substring() // type error

정리하자면 타입은 값의 능력이고, 능력에 벗어난 일을 시키면 타입 오류가 발생합니다.

타입으로 견고하게란 무엇일까?

버그의 대다수는 타입 오류입니다.

그렇다면 타입 오류를 최대한 줄이는것이 중요하겠습니다.

Airbnb는 타입스크립트 도입으로 버그의 38%를 예방할 수 있었습니다.

어떻게 타입스크립트 도입만으로 버그를 줄일수 있었던 것일까요?

타입스크립트는 타입 검사기를 통해 우리가 작성한 소스코드에 값의 능력에 벗어난 사용여부를 검사하여,

값의 능력에 벗어난 일을 시켰다면 컴파일을 거부 합니다.

정적 타입 언어인 타입스크립트와 동적 타입 언어인 자바스크립트를 비교해서 예를들면 다음과 같습니다.

자바스크립트로 작성된 코드는 타입 에러가 런타임에서 발생하는 반면,

타입스크립트로 작성된 코드는 타입 에러를 컴파일시(컴파일 옵션을 통해 선택할 수 있기는 합니다) 발견할 수 있습니다.

즉 정적 타입 언어인 타입스크립트를 사용하면 타입 오류를 컴파일 단계에서 미리 발견하고 수정할 수 있습니다.

이로 인해 런타임에서 발생할 수 있는 타입 관련 오류를 사전에 방지할 수 있게되어,

결과적으로 더 견고한 소프트웨어를 개발할 수 있습니다.

타입스크립트의 탄생 배경

2010년 즈음에 기본 브라우저를 인터넷 익스플로어에서 크롬으로 변경했던 기억이 납니다.

당시 인터넷 익스플로어는 웹 사이트가 뜨기까지 수 초를 기다려야 했는데, 크롬은 그에 비해 아주 빠릿빠릿했습니다.

크롬은 v8 엔진으로 자바스크립트 실행 속도 개선을 포함한 전반적인 아키텍처 개선으로 이를 가능케 했습니다.

마이크로소프트는 자바스크립트 엔진의 빠른 속도 덕분에 자바스크립트로 작성된 더 큰 소프트웨어인 vscode를 만들기 시작했습니다.

그런데 약 7천 줄의 코드를 작성할 때 문제가 발생했습니다.

버그를 찾는 데 한나절이 걸리는 것이었습니다.

타입 정보가 없기에 런타임에서 버그를 찾아야 했고 디버거에 의존해야만 했습니다.

그래서 런타임이 아닌 컴파일 단계에서 버그를 찾을 수 있도록 정적 타입 언어인 타입스크립트를 개발하기 시작했습니다.

다형성으로 유연하게

책에서는 '다형성으로 유연하게'를 설명하기 위해 다음 챕터들로 구성되어 있습니다.

- 서브타입에 의한 다형성 
- 매개변수에 의한 다형성
- 두 다형성의 만남
- 오버로딩에 의한 다형성

해당 포스팅에서는 가장 기본적인 서브타입에 의한 다형성을 이야기 하고자 합니다.

마찬가지로 다형성의 정의부터 시작해보겠습니다.

다형성이란 무엇일까?

다형성이란 무엇일까요?

저자는 다음과 같이 설명합니다.

한 개체가 여러 타입에 속하는 것.

한 개체가 여러 타입에 속하기 위해서 정적 타입 언어가 제공하는 기능중 하나가 서브타입에 의한 다형성입니다.

새로운 용어가 나왔네요.

계속해서 서브타입을 알아보겠습니다.

서브타입이란 무엇일까?

서브타입은 무엇일까요?

저자는 다음과 같이 설명합니다.

서브타입은 'A는 B이다'의 관계를 만족하는것을 뜻합니다.

'학생은 사람이다.'라는 문장은 'A는 B이다.' 관계를 만족하므로

'학생은 사람의 서브타입이다.' 로 바꿔말할 수 있습니다.

책에서는 식당을 예시로 듭니다.

식당은 사람이 입장할 수 있습니다. 학생도 사람이므로 식당에 입장할 수 있습니다.

하지만 학생만 입장할 수 있는 식당은 사람은 입장할 수 없습니다.

모든 사람은 학생이 아니기 때문이죠.

서브타입 관계를 타입 검사기에 알리는 extends 키워드

앞선 '학생은 사람이다.'에서 'A는 B이다.'의 관계는 사람에게는 직관적이지만, 타입 검사기 입장에서는 아닙니다.

식당에 사람을 입장시키는 함수를 예시로 들어보겠습니다.

class Person {
  name: string
  
  constructor(name: string) {
    this.name = name
  }
}
class Student {
  name: string;

  constructor(name: string) {
    this.name = name
  }
}

const person = new Person('Kim')
const student = new Student('Park')

const enterRestaurant = (p: Person) => {}

enterRestaurant(person) // ok
enterRestaurant(student) // error

Person의 인스턴스인 person과 Student의 인스턴스인 student를 enterRestaurant 함수의 인자로 전달시 타입 검사를 통과 할 수 있어야 합니다.

왜냐하면 직관적으로 학생은 사람이기 때문이죠.

하지만 이것은 우리의 직관일 뿐, 타입 검사를 통과하기 위해선 타입 검사기에 두 클래스의 관계를 알려야합니다.

class Person {}
class Student extends Person {}

extends 키워드를 통해 둘은 서브타입 관계임을 나타낼 수 있습니다.

이제 타입 검사기는 학생과 사람의 관계를 이해하여 우리의 직관과 동일하게 할당 여부를 판단할 수 있게 되었습니다.

여기까지 읽었다면, 뭔가 의아할 수 있습니다.

타입스크립트에서 타입 검사기는 타입 오류를 내지 않고, 위의 코드를 통과시키기 때문입니다.

enterRestaurant(person) // ok
enterRestaurant(student) // ok

타입스크립트는 extends 키워드를 사용하지 않아도 서브타입 관계를 추론할 수 있습니다.

이러한 동작은 구조적 타이핑이라고 합니다.

서브타입과 다형성에 대해 알아봤으므로 우선 책의 제목인 서브타입에 의한 다형성에 대한 의미를 짚고 넘어가겠습니다.

서브타입에 의한 다형성이란 무엇일까?

앞에서 서브타입과 다형성의 의미를 각각 알아보았습니다.

서브타입은 'A는 B이다.'의 관계를 만족하고, 타입 검사기에는 'extends' 키워드로 알려야 한다구요.

또한 다형성이란 '한 개체가 여러 타입에 속하는 것'이구요.

그렇다면 서브타입에 의한 다형성이란 다음과 같이 말할수 있을것 같습니다.

상속 관계(A는 B이다 관계)를 통해 한 객체가 여러 타입으로 취급될 수 있게 하는 것.

이를 통해 상위 타입을 요구하는 곳에 하위 타입의 객체를 사용할 수 있게 되어, 코드의 유연성과 재사용성이 높아집니다.

유명한 예시로는 JAVA에서 List 타입의 구현체로 ArrayList, LinkedList가 있지만,

타입 지정시 구현이 아닌 List 타입으로 한다는것을 생각해보시면 좋을것 같습니다.

구조적 타이핑이란 무엇일까?

다시 돌아와서 타입스크립트의 구조적 타이핑에 대해 알아보도록 하겠습니다.

extends로 상속 관계를 명시적으로 작성하지 않았는데 통과되는 이유는 무엇일까요?

타입스크립트의 타입 검사기가 사람의 직관과 동일하게 동작하는 것이기라도 할까요?

이 또한 규칙이 존재합니다.

타입스크립트는 상속 관계와 상관 없이 '구조를 통해 서브타입 관계를 추론'하기 때문입니다.

앞서 살펴본 코드를 다시 보겠습니다.

class Person {
  name: string
  
  constructor(name: string) {
    this.name = name
  }
}
class Student {
  name: string;

  constructor(name: string) {
    this.name = name
  }
}

const person = new Person('Kim')
const student = new Student('Park')

const enterRestaurant = (p: Person) => {}

enterRestaurant(person) // ok
enterRestaurant(student) // error

enterRestaurant 함수의 파라미터 타입은 Person입니다.

Person의 구조는 다음과 같습니다.

interface Person {
  name: string
}

Student의 구조 또한 Person과 동일합니다.

interface Student {
  name: string
}

Person과 Student는 동일한 구조이므로 타입 검사기는 타입 검사를 통과시킵니다.

두 객체를 비교할 때 이름이 어떻냐가 중요한 것이 아니라 구조를 중요하게 보는것

이를 구조적 타이핑(structural typing)이라고 합니다.

extends 키워드를 사용한 상속 기반의 '서브타입에 의한 다형성'보다 좀 더 유연하게 사용할 수 있는 것이죠.

한편 구조적 타이핑의 예외 사항이 존재하는데요. 계속해서 살펴보겠습니다.

잉여 속성 검사란 무엇일까?

앞서 타입을 값의 능력으로 정의 했습니다.

함수에 타입을 정의하는것은 정의한 타입의 능력만을 함수에서 사용하겠다는 것을 의미합니다.

const enterRestaurant = (p: Person) => {}

위 함수는 파라미터로 Person을 받고 Person 타입의 능력만을 사용함을 의미합니다.

따라서 추가적인 능력을 가진 객체를 전달해도 상관 없을것 입니다.

const kim = { name: 'kim', language: 'ko' }

enterRestaurant(kim) // ok

하지만 위처럼 변수에 값을 할당하고 함수의 파라미터에 변수를 할당하는것이 아닌,

객체 리터럴 표기법으로 객체를 생성해 파라미터로 직접 넘기면 타입스크립트의 타입 검사기는 타입 에러를 냅니다.

enterRestaurant({name: 'kim', fly: () => console.log('I can fly')}) // error

리터럴 표기법으로 객체를 생성할 경우 이는 재사용 되지 않고, 함수 내부에서만 사용되게 됩니다.

함수 밖에서 해당 객체를 참조할 이름이 없기 때문이죠.

함수 내부에서만 사용되는데, 추가적인 능력을 전달하는것은 함수가 추가 능력이 필요한 것 처럼 오해의 소지가 있습니다.

따라서 객체 리터럴을 직접 전달할 경우 더욱 엄격하게 검사하여 타입 에러를 내도록 예외사항을 두었습니다.

이를 잉여 속성 검사라 합니다.

이에 대한 이유를 깊이 있게 알고 싶으신 분은 TypeScript 타입 시스템 뜯어보기: 타입 호환성을 참고해보시면 좋을것 같습니다 :)

타입스크립트 탄생 배경에서 살펴본 구조적 타이핑

타입스크립트의 탄생 배경을 살펴보면 구조만으로 서브타입 관계를 추론하게 된 이유를 추측할 수 있습니다.

아시다시피 자바스크립트가 먼저 나오고 2014년도에 타입스크립트 1 버전이 출시되었습니다.

이미 자바스크립트로 수많은 객체들이 생성되어 있었습니다.

extends로 서브타입 관계를 표현하기엔 수많은 타입을 추가로 작성해야만 합니다.

자바스크립트에서 타입스크립트로 마이그레이션에 허들이 될 수 있는것이죠.

따라서 호환성과 점진적 도입을 위해 구조만 일치하면 같은 타입으로 추론될 수 있도록 타입스크립트를 유연하게 설계하게 되었습니다.

마무리

여러 다형성 중 아직은 포스팅에서 설명한 서브타입에 의한 다형성 정도만 명확히 이해 했다는 생각이 듭니다.

그럼에도 불구하고 책을 읽고 지식이 촘촘해지는 느낌이 좋았습니다.

더 많이 활용해보고, 시간을 두어 다시 읽게 된다면 미처 이해하지못한 더 많은 다형성에 대한 이야기를 이해할 수 있을것 같습니다.

추후 성장하여 또 한 번 읽게 될 날을 기대합니다.